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1. Abstract 


This document defines the "administratively scoped IPv4 multicast 
space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it 
describes a simple set of semantics for the implementation of 
Administratively Scoped IP Multicast. Finally, it provides a mapping 
between the IPv6 multicast address classes [RFC1884] and IPv4 
multicast address classes. 


This memo is a product of the MBONE Deployment Working Group (MBONED) 
in the Operations and Management Area of the Internet Engineering 
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author. 


2. Acknowledgments 
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3. Introduction 


Most current IP multicast implementations achieve some level of 
scoping by using the TTL field in the IP header. Typical MBONE 
(Multicast Backbone) usage has been to engineer TTL thresholds that 
confine traffic to some administratively defined topological region. 
The basic forwarding rule for interfaces with configured TTL 
thresholds is that a packet is not forwarded across the interface 
unless its remaining TTL is greater than the threshold. 
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TTL scoping has been used to control the distribution of multicast 
traffic with the objective of easing stress on scarce resources 
(e.g., bandwidth), or to achieve some kind of improved privacy or 
scaling properties. In addition, the TTL is also used in its 
traditional role to limit datagram lifetime. Given these often 
conflicting roles, TTL scoping has proven difficult to implement 
reliably, and the resulting schemes have often been complex and 
difficult to understand. 


A more serious architectural problem concerns the interaction of TTL 
scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The 
particular problem is that in many common cases, TTL scoping can 
prevent pruning from being effective. Consider the case in which a 
packet has either had its TTL expire or failed a TTL threshold. The 
router which discards the packet will not be capable of pruning any 
upstream sources, and thus will sink all multicast traffic (whether 
or not there are downstream receivers). Note that while it might seem 
possible to send prunes upstream from the point at which a packet is 
discarded, this strategy can result in legitimate traffic being 
discarded, since subsequent packets could take a different path and 
arrive at the same point with a larger TTL. 


On the other hand, administratively scoped IP multicast can provide 
clear and simple semantics for scoped IP multicast. The key 
properties of administratively scoped IP multicast are that (i). 
packets addressed to administratively scoped multicast addresses do 
not cross configured administrative boundaries, and (ii). 
administratively scoped multicast addresses are locally assigned, and 
hence are not required to be unique across administrative boundaries. 


4. Definition of the Administratively Scoped IPv4 Multicast Space 


The administratively scoped IPv4 multicast address space is defined 
to be the range 239.0.0.0 to 239.255.255.255. 


5. Discussion 


In order to support administratively scoped IP multicast, a router 
should support the configuration of per-interface scoped IP multicast 
boundaries. Such a router, called a boundary router, does not forward 
packets matching an interface’s boundary definition in either 
direction (the bi-directional check prevents problems with multi- 
access networks). In addition, a boundary router always prunes the 
boundary for dense-mode groups [PIMDM], and doesn’t accept joins for 
sparse-mode groups [PIMSM] in the administratively scoped range. 
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6. The Structure of the Administratively Scoped Multicast Space 


The structure of the IP version 4 administratively scoped multicast 
space is loosely based on the IP Version 6 Addressing Architecture 
described in RFC 1884 [RFC1884]. This document defines two important 
scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These 
scopes are described below. 


6.1. The IPv4 Local Scope -- 239.255.0.0/16 


239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local 
Scope is the minimal enclosing scope, and hence is not further 
divisible. Although the exact extent of a Local Scope is site 
dependent, locally scoped regions must obey certain topological 
constraints. In particular, a Local Scope must not span any other 
scope boundary. Further, a Local Scope must be completely contained 
within or equal to any larger scope. In the event that scope regions 
overlap in area, the area of overlap must be in its own local scope. 
This implies that any scope boundary is also a boundary for the Local 
Scope. The more general topological requirements for administratively 
scoped regions are discussed below. 


6.1.1. Expansion of the IPv4 Local Scope 


The IPv4 Local Scope space grows "downward". As such, the IPv4 Local 
Scope may grow downward from 239.255.0.0/16 into the reserved ranges 
239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not 
be utilized until the 239.255.0.0/16 space is no longer sufficient. 


6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14 


239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, 
and is the space from which an organization should allocate sub- 
ranges when defining scopes for private use. 


6.2.1. Expansion of the IPv4 Organization Local Scope 


The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are 
unassigned and available for expansion of this space. These ranges 
should be left unassigned until the 239.192.0.0/14 space is no longer 
sufficient. This is to allow for the possibility that future 
revisions of this document may define additional scopes on a scale 
larger than organizations. 


6.3. Other IPv4 Scopes of Interest 


The other two scope classes of interest, statically assigned link- 
local scope and global scope already exist in IPv4 multicast space. 
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The statically assigned link-local scope is 224.0.0.0/24. The 
existing static global scope allocations are somewhat more granular, 
and include 


224.1.0.0-224.1.255.255 ST Multicast Groups 
224.2.0.0-224.2.127.253 Multimedia Conference Calls 
224.2.127.254 SAPvl Announcements 
224.2.127.255 SAPvO Announcements (deprecated) 
224.2.128.0-224.2.255.255 SAP Dynamic Assignments 
224.252.0.0-224.255.255.255 DIS transient groups 
232.0.0.0=232 2.255.255.2559 VMTP transient groups 


See [RFC1700] for current multicast address assignments (this list 
can also be found, possibly in a more current form, on 
ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-—addresses) . 


7. Topological Requirements for Administrative Boundaries 


An administratively scoped IP multicast region is defined to be a 
topological region in which there are one or more boundary routers 
with common boundary definitions. Such a router is said to be a 
boundary for scoped addresses in the range defined in its 
configuration. 


Network administrators may configure a scope region whenever 
constrained multicast scope is required. In addition, an 
administrator may configure overlapping scope regions (networks can 
be in multiple scope regions) where convenient, with the only 
limitations being that a scope region must be connected (there must 
be a path between any two nodes within a scope region that doesn’t 
leave that region), and convex (i.e., no path between any two points 
in the region can cross a region boundary). However, it is important 
to note that if administratively scoped areas intersect 
topologically, then the outer scope must consist of its address space 
minus the address spaces of any intersecting scopes. This requirement 
prevents the problem that would arise when a path between two points 
in a convex region crosses the boundary of an intersecting region. 
For this reason, it is recommended that administrative scopes that 
intersect topologically should not intersect in address range. 


Finally, note that any scope boundary is a boundary for the Local 
Scope. This implies that packets sent to groups covered by 
239.255.0.0/16 must not be forwarded across any link for which a 
scoped boundary is defined. 
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8. Partitioning of the Administratively Scoped Multicast Space 
The following table outlines the partitioning of the IPv4 multicast 
space, and gives the mapping from IPv4 multicast prefixes to IPv6 
SCOP values: 


IPv6 SCOP RFC 1884 Description IPv4 Prefix 


reserved 

node-local scope 

link-local scope 224.0.0.0/24 
(unassigned) 239.255.0.0/16 
(unassigned) 

site-local scope 

(unassigned) 

(unassigned) 

organization-local scope 239.192.0.0/14 
(unassigned) 

(unassigned) 

(unassigned) 

(unassigned) 

global scope 224.0 :1:00=238 52552255255 
reserved 

(unassigned) 239.0.0.0/10 
(unassigned) 239.64.0.0/10 
(unassigned) 239.128.0.0/10 


HTHUAWPAINDUABRWNEO 


9. Structure and Use of a Scoped Region 


The high order /24 in every scoped region is reserved for relative 
assignments. A relative assignment is an integer offset from highest 
address in the scope and represents a 32-bit address (for IPv4). For 
example, in the Local Scope defined above, 239.255.255.0/24 is 
reserved for relative allocations. The de-facto relative assignment 
"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for 
SAP [SAP]. The next relative assignment, "1", corresponds to the 
address 239.255.255.254 in the Local Scope. The rest of a scoped 
region below the reserved /24 is available for dynamic assignment 
(presumably by an address allocation protocol). 


In is important to note that a scope discovery protocol [MZAP] will 
have to be developed to make practical use of scopes other than the 
Local Scope. In addition, since any use of any administratively 
scoped region, including the Local Scope, requires dynamically 
assigned addressing, an Address Allocation Protocol (AAP) will need 
to be developed to make administrative scoping generally useful. 
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9.1. Relative Assignment Guidelines 


Requests for relative assignments should be directed to the IANA. The 
IANA will be advised by an area expert when making relative address 
assignments. The area expert will be appointed by the relevant Area 
Director. 


In general, relative addresses will be used only for bootstrapping to 
dynamic address assignments from within the scope. As such, relative 
assignments should only be made to those services that cannot use a 
dynamic address assignment protocol to find the address used by that 
service within the desired scope, such as a dynamic address 
assignment service itself. 


10. Security Considerations 


It is recommended that organizations using the administratively 
scoped IP Multicast addresses not rely on them to prevent sensitive 
data from being transmitted outside the organization. Should a 
multicast router on an administrative boundary be mis-configured, 
have a bug in the administrative scoping code, or have other problems 
that would cause that router to forward an administratively scoped IP 
multicast packet outside of the proper scope, the organizations data 
would leave its intended transmission region. 


Organizations using administratively scoped IP Multicasting to 
transmit sensitive data should use some confidentiality mechanism 
(e.g. encryption) to protect that data. In the case of many existing 
video-conferencing applications (e.g. vat), encryption is available 
as an application feature and merely needs to be enabled (and 
appropriate cryptographic keys securely distributed). For many other 
applications, the use of the IP Encapsulating Security Payload (ESP) 
[RFC-1825, RFC-1827] can provide IP-layer confidentiality though 
encryption. 


Within the context of an administratively scoped IP multicast group, 
the use of manual key distribution might well be feasible. While 
dynamic key management for IP Security is a research area at the time 
this note is written, it is expected that the IETF will be extending 
the ISAKMP key management protocol to support scalable multicast key 
distribution in the future. 


It is important to note that the "boundary router" described in this 
note is not necessarily providing any kind of firewall capability. 
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13. Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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